home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000006_owner-urn-ietf _Mon Oct 7 22:11:08 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA25760 for urn-ietf-out; Mon, 7 Oct 1996 22:11:08 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA25754 for <urn-ietf@services.bunyip.com>; Mon, 7 Oct 1996 22:10:59 -0400
  3. Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA09898  (mail destined for urn-ietf@services.bunyip.com); Mon, 7 Oct 96 22:10:27 -0400
  5. Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <15478(7)>; Mon, 7 Oct 1996 19:10:23 PDT
  6. Received: by golden.parc.xerox.com id <2771>; Mon, 7 Oct 1996 19:10:09 PDT
  7. To: rdaniel@acl.lanl.gov
  8. Cc: urn-ietf@bunyip.com
  9. In-Reply-To: <2.2.32.19961007170633.006b019c@acl.lanl.gov> (message from Ron
  10.     Daniel on Mon, 7 Oct 1996 10:06:33 PDT)
  11. Subject: [URN] advantages of NAPTR over PURLs
  12. From: Larry Masinter <masinter@parc.xerox.com>
  13. Message-Id: <96Oct7.191009pdt."2771"@golden.parc.xerox.com>
  14. Date: Mon, 7 Oct 1996 19:10:09 PDT
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Larry Masinter <masinter@parc.xerox.com>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. Ron & I have been offline, but I thought I'd move the discussion back
  21. onto list... It's not that I'm a PURL bigot, but I think www.purl.org
  22. has an interesting simplicity and that pushing on PURL vs. NAPTR
  23. really gets at what the _actual_ advantages might be.
  24.  
  25.  
  26. Re replication:
  27.  
  28. > We can provide multiple A records for www.purl.org, but there is no
  29. > way to do smart prioritization between the more and less capable
  30. > hosts.
  31.  
  32. Why is this easier to do with NAPTR records than A records? Could we
  33. extend A records for HTTP servers so that you could do smart
  34. prioritization? ("If this is such a great idea, why save it for
  35. URNS"). 
  36.  
  37. > Depending on how the multiple A records are provided, there may also
  38. > be an obscure error that truncates the list of responses. The NAPTR
  39. > proposal will not suffer that error.
  40.  
  41. Is this a bug in the implementation of DNS? If the bug is there for A
  42. records, why wouldn't it be there for NAPTR records? Is this a design
  43. error that could be fixed?
  44.  
  45. > The real point of the NAPTR proposal is that it gives us a way to cope
  46. > with names, such as www.purl.org, that should be long-lived but aren't.
  47.  
  48. I don't understand why www.purl.org must have a shorter lifetime than
  49. any NAPTR name. You just vow to not reassign the name. If you can't do
  50. that with ".org", then pick a new top level domain.
  51.  
  52. >>Well, www.purl.org can migrate, too, can't it?
  53. > I'm sorry I wasn't clear. By "migrating a resolver" I mean moving it onto
  54. > a machine that cannot be identified by the domain name that was used
  55. > for the earlier resolver, and terminating service on the original machine,
  56. > even if that machine remains up and running for other purposes.
  57. > So, no, www.purl.org cannot migrate according to my definition. (Better
  58. > terminology welcomed).
  59.  
  60. If you want to be able to migrate PURL resolvers to other machines,
  61. you just assign a new IP address to the PURL resolver name. This is
  62. completely flexible. Don't use that DNS name for anything other than
  63. PURL resolution service. E.g., call it <scheme>.resolver.purl.org
  64. instead of just www.purl.org.
  65.  
  66. The DNS entries for resolver.purl.org already give you all the
  67. indirection you need. Why add more?
  68.  
  69. >>> and the resolution process allows multiple protocols
  70. >>The URL in the 'Location:' header of purl.org's response need not be
  71. >>'http:'.
  72.  
  73. >We are not talking about the same thing. One could assign PURLs such as
  74. >   ftp://purl.foo.com/whatever
  75. >but once that PURL is assigned, we have to use FTP to resolve it. Since
  76. >the NAPTR draft doesn't require the resolution protocol to be embedded in
  77. >the identifier, we are free to offer multiple resolution protocols and to
  78. >change them over time. This is an important point, since over time we
  79. >will have increasingly efficient protocols.
  80.  
  81. In the "PURL" method, the "resolution" is accomplished by using HTTP
  82. to talk to the resolution service and (if what you do is a GET)
  83. getting back a "303" response with a Location: header to do the
  84. URN->URL mapping.
  85.  
  86. If you want "PURL" resolution to not be embedded in the URN, then
  87. define a translation from URN notation to PURL by, for example,
  88. defining that:
  89.  
  90.       <scheme>:<docid>
  91.  
  92.         is (currently) implemented by translating it into
  93.  
  94.           http://<scheme>.resolver.purl.org/<docid>'
  95.  
  96. and now you have a resolution implementation that doesn't embed the
  97. resolution protocol in the name. Of course, you are free to offer
  98. other resolution protocols besides HTTP and change them over time.
  99. E.g., define that
  100.  
  101.   isbn:1-56604-355-7
  102.     =>  http://isbn.resolver.purl.org/1-56604-355-7
  103.   issn:1077-2014
  104.     =>  http://issn.resolver.purl.org/1077-2014
  105.  
  106.  
  107. > For PURLs, we not only have to know the identifier, we have to know
  108. > what resolver to contact. We end up with things like:
  109. >   http://purl.bowker.com/isbn/1-56604-355-7
  110. >   http://purl.agicoa.com/isan/9961231234567891
  111.  
  112. oh no! Clearly you only want to use the resolver.purl.org name.
  113.  
  114. Larry
  115.  
  116.